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This paper motivates why Real-Time Maude should be well suited to provide a formal semantics and 
formal analysis capabilities to modeling languages for embedded systems. One can then use the code 
generation facilities of the tools for the modeling languages to automatically synthesize Real-Time 
Maude verification models from design models, enabling a formal model engineering process that 
combines the convenience of modeling using an informal but intuitive modeling language with formal 
verification. We give a brief overview six fairly different modeling formalisms for which Real-Time 
Maude has provided the formal semantics and (possibly) formal analysis. These models include 
behavioral subsets of the avionics modeling standard AADL, Ptolemy II discrete-event models, two 
EMF-based timed model transformation systems, and a modeling language for handset software. 



1 Introduction 



It is now acknowledged that one of the most promising approaches to inject formal methods into indus- 
trial model-driven engineering is to endow the domain-specific modeling languages used in industry with 
formal verification capabilities. This can be achieved by defining the formal semantics of the informal 
modeling language, and then automatically synthesize a formal verification model from the informal de- 
sign model. This enables a formal model engineering process that combines the convenience of modeling 
using an informal but intuitive modeling language with formal verification. Furthermore, the synthesis 
of the verification model can take advantage of the code generation infrastructure provided by a num- 
ber of advanced modeling tools to support the generation of deployment code from design models; this 
infrastructure can also be used to generate a formal model. 

For the formal model engineering process to be useful in practice, the target formal language and tool 
must not only be expressive enough to define the formal semantics of the informal language and provide 
automated simulation and model checking capabilities, but should also 

1 . allow the users to define formal analysis commands without understanding the formal language or 
the formal representation of their models; and 

2. provide formal analysis results, such as counterexamples in temporal logic model checking, that 
the user can easily understand. 

Formal model engineering is crucial for real-time embedded systems (RTESs) — such as automotive, 
avionics, and medical systems — that are hard to design correctly, since subtle timing aspects impact 
system functionality, yet are safety-critical systems whose failures may cause great damage to persons 
and/or valuable assets. There exist a number of formal analysis tools for real-time systems (see [29] for 
a survey). However, there is a significant gap between the formalisms of these tools, such as timed au- 
tomata [2] or timed Petri nets [9 , 28 ], that sacrifice expressiveness for decidability, and the expressiveness 
of modeling languages for industrial RTESs, that were, after all, designed for modeling convenience. 

In contrast to such formal tools, Real-Time Maude [22J — which extends the rewriting-logic-based 
Maude system ifTUll to support the formal specification, simulation, and model checking of real-time 
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systems — emphasizes expressiveness and ease of specification over algorithmic decidability of key prop- 
erties. In Real-Time Maude, the state space and the functional properties of the system are defined as 
an equational specification, the instantaneous local transitions are modeled as rewrite rules, and time ad- 
vance is modeled by tick rewrite rules. Real-Time Maude is particularly suitable for modeling real-time 
systems in an object-oriented style. Because of its expressiveness, Real-Time Maude has been success- 
fully applied to a wide range of advanced state-of-the-art systems that are beyond the pale of timed 
automata, including wireless sensor networks algorithms |[T3l l24l . scheduling algorithms that require 
unbounded queues [21], and large multicast protocols ll23l[T5ll . 

Real-Time Maude's natural model of time, together with its expressiveness, should make it a suitable 
semantic framework for modeling languages for RTESs; such languages then also get the following 
formal analysis capabilities for free: 

• simulation; 

• reachability analysis; 

• linear temporal logic (LTL) model checking for for untimed LTL properties, as well as time- 
bounded LTL model checking for analyzing systems with an infinite reachable state space; and 

• TCTL<> model checking of timed CTL formulas lfl4l . 

It is also worth mentioning that the use of both equations (to define the functional aspects of the system) 
and rewrite rules (to model its concurrent transitions) makes model checking significantly more efficient 
than if deterministic behaviors were also encoded as rules, since only rewrite rules contribute to the 
reachable state space. 

The possibility to equationally define parametric atomic state propositions (and "state patterns" for 
reachability analysis) in Real-Time Maude allows us to predefine a useful set of parametric state propo- 
sitions in the Real-Time Maude interpreter of a language. These propositions make it easy for the user 
to define his/her search and LTL model checking commands without having to understand Real-Time 
Maude or the formal representation of his/her model, as illustrated in this paper. 

A key requirement to (i) understand the results of Real-Time Maude analyses, and (ii) being able to 
map them back into the original modeling formalism is to have, respectively, a small representational 
distance between the original models and their formal counterparts, and a one-to-one correspondence 
between these models. Since hierarchical composition and encapsulation play key roles in industrial 
modeling languages, the possibility of defining hierarchical objects enable us to achieve both goals. 

In this extended abstract, I give an overview of six fairly different modeling languages for RTESs that 
have a Real-Time Maude semantics, and briefly explain how they have been endowed with Real-Time 
Maude, or in some cases Maude, simulation and model checking capabilities. Papers on the semantics 
of each modeling have been published elsewhere |[T1 |3l |4l |8l [T9l I25TL 

2 Behavioral AADL 

The Architecture Analysis & Design Language (AADL) 1271 is an industrial standard used in avionics, 
aerospace, automotive, medical devices, and robotics communities to describe a performance-critical 
embedded real-time system as an assembly of software components mapped onto an execution platform. 
In joint work with Jose Meseguer, I have defined the Real-Time Maude semantics of a subset of the 
software components of AADL. This subset defines the architectural and behavioral specification of a 
system as a set of hierarchical components with ports and connections, and with the behaviors defined by 
Turing-complete transitions systems. The references |fl9l l20l explain the Real-Time Maude semantics 
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for the targeted fragment of AADL in detail. In particular, the semantics of a component-based language 
can naturally be defined in an object-oriented style, where each component instance is modeled as an 
object, and where the hierarchical structure of components is reflected in the nested structure of objects. 

Together with Artur Boronat, we have developed the AADL2Maude plug-in for the Open Source 
AADL Tool Environment (OSATE), which is a set of Eclipse plug-ins. AADL2Maude uses OSATE's 
code generation facility to automatically generate Real-Time Maude specifications from AADL models. 
However, the Real-Time Maude analysis itself is not yet integrated into OSATE. 

To allow the user to conveniently define his/her search and model checking commands without know- 
ing Real-Time Maude or the Real-Time Maude representation of AADL models, we have defined some 
useful functions and parametrized state propositions. For example, the term 

value of v in component fullComponentName in glob alComp orient 

gives the value of the state variable v in the thread identified by the full name, fullComponentName in the 
system globalComponent. Likewise, 

location of component fullComponentName in globalComponent 

gives the current location/state in the transition system in the given thread. 

We have applied the AADL2Maude code generator and Real-Time Maude to formally analyze an 
AADL model, developed by Min Young Nam and Lui Sha at UIUC, of a simple network of medical 
devices, consisting of a controller, a ventilator machine that assists a patient's breathing during surgery, 
and an X-ray device |JT8 ]. Whenever a button is pushed to take an X-ray, the ventilator machine should 
pause for two seconds, starting one second after the button is pushed, and the X-ray should be taken after 
two seconds. The initial state is {MAIN system Wholesys . impl }, and MAIN -> Xray -> 
xmPr -> xmTh denotes the full name of the X-ray machine thread. The ventilator machine must be 
pausing when an X-ray is being taken, so that the X-ray is not blurred. The following search command 
checks whether an undesired state, where the X-ray thread xmTh is in local state xray while the ven- 
tilator thread vmTh is not in state paused, can be reached from the initial state (the unexpected result 
shows a concrete unsafe state that can be reached from the initial state): 

Maude> (utsearch [1] 

{MAIN system Wholesys . impl} =>* {C -.Configuration} 
such that 
((location of component (MAIN -> Xray -> xmPr -> xmTh) 

in C -.Configuration) == xray 
and (location of component (MAIN -> Ventilator -> vmPr -> vmTh) 
in C : Configuration) =/= paused) .) 

Solution 1 C : Configuration — > ... 

For LTL and timed CTL model checking purposes, our tool has pre-defined useful parametric atomic 
propositions, such as full thread name @ location, which holds when the thread is in state location, and 
value of variable in component full thread name is value, which holds if the current value of 
the local transition system variable variable in the given thread equals value. 

We can use time-bounded LTL model checking to verify that an X-ray must be taken within three 
seconds of the start of the system (this command returned a counter-example revealing a subtle and 
previously unknown design error): 

Maude> (mc {MAIN system Wholesys . impl} \=t 

<> ((MAIN -> Xray -> xmPr -> xmTh) @ xray) in time <= 3 . ) 

Result ModelCheckResult : counterexample ( ... ) 
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3 Synchronous AADL 

In a number of systems targeted by AADL, such as integrated modular avionics systems and distributed 
control systems in motor vehicles, the system design is essentially a synchronous design that must re- 
alized in an asynchronous distributed setting. The key idea of the PALS architectural pattern |[T6l [T7I 
is to reduce the design, verification, and implementation of a distributed real-time system to that of its 
much simpler synchronous version, provided that the network infrastructure guarantees bounds on the 
messaging delays and the skews of the local clocks. For a synchronous design SD and network bounds 
r, we then have a semantically equivalent asynchronous distributed design PALS(SD,F). Not only is this 
important from a system design perspective, but it also makes model checking verification feasible. For 
example, in [ 16 ] we show that for the avionics system mentioned below, the synchronous design model 
has 185 reachable states and can be model checked in less than a second in Maude, whereas — even re- 
stricted to perfect local clocks and message delays and 1 — the corresponding asynchronous model has 
more than 3 million reachable states and cannot be model checked in reasonable time. 

To allow modelers to take advantage of PALS while using AADL, I have, in joint work with Kyung- 
min Bae, Jose Meseguer, and Abdullah Al-Nayeem, identified a "synchronous subset" of behavioral 
AADL, called Synchronous AADL, that is suitable to define the synchronous PALS designs in AADL (3J- 

To support formal model engineering, we have integrated the Real-Time Maude analysis of Syn- 
chronous AADL models into OSATE. The SynchAADLlMaude tool is an OSATE plug-in that uses 
OSATE's model traversal facility to both support the generation of a Real-Time Maude model from 
an Synchronous AADL instance model, and for analyzing the synthesized Real-Time Maude model 
from within OSATE. SynchAADLlMaude inherits the convenient predefined atomic propositions from 
our AADL analysis library, and also allows the modeler to define new formulas and LTL model checking 
commands in XML within OSATE. 

We have used SynchAADLlMaude to verify a Synchronous AADL model of an avionics system 
based on a specification by Steve Miller and Darren Cofer at Rockwell-Collins IfTTI . Figure [T] shows the 
SynchAADLlMaude window for this example. Real-Time Maude code generation and model checking 
are performed by clicking on the Code Generation button and the Do Verification button, 
respectively. The LTL properties that the avionics system should satisfy have been entered into the tool, 
and are shown in the "AADL Property Requirement" table. The Do Verification button has been 
clicked and the results of the model checking are shown in the "Maude Console." 

The properties to be verified are managed by the associated XML property file. For example, to add 
an LTL model checking command to verify a property Rl defined as the LTL formula below, we just add 
the following command tag to the property file: 

<command> 
<name>Rl</name> 
<value type = "ltl"> 
[] (noChangeAssumptionNextState 

-> (agreeOnActiveSide \/ (noSideFailed -> agreeOnActiveSide) ) ) 
</value> 
</command> 

New formulas can be defined in the property file using the definition tag. For example, a new 
constant sidelFailed, can be defined as follows: 

<def inition> 
<name>sidelFailed</name> 
<value> 
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5yneAADL2Maude Verification 
AADL Instance Model 
Model Location: 
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side2FullyAv-aiVable SJ m-anSelecfcPressed \/ sidelFailed)) in 
M-ain_ActiveStandbySystem_\mpl_Instance-VERIFICATION-DEF with mode 
deterministic time increase 

Result Bool ; 
true 



Figure 1: SynchAADL2Maude window in OS ATE. 



value of sidelFailed in component 
(MAIN -> sideOne -> sideProcess 
</value> 
</definition> 



-> sideThread) is true 



4 Ptolemy II Discrete-Event Models 

Ptolemy II ifTTTl is a well-established modeling and simulation tool used in industry that provides a pow- 
erful yet intuitive graphical modeling language. A Ptolemy II model consists of a set of interconnected 
actors with input ports and output ports, where communication channels pass events from one port to 
another. Such a model can be encapsulated as a composite actor, which may also have input and output 
ports. In Ptolemy II, real-time systems are modeled as discrete-event (DE) models. Like many graphical 
modeling languages, Ptolemy II DE models lack formal verification capabilities. 

In each iteration of a DE model, all components with input execute synchronously. Since connections 
are instantaneous and the components execute in lock-step, we must compute the fixed point of the input 
for each component in the round before its execution; this input comes from the output of another actor's 
execution in the same synchronous round. Formalizing the Ptolemy II DE modeling language is fairly 
challenging as it combines a synchronous fixed-point semantics with time and hierarchical models, as 
well as a powerful expression language. 

Real-Time Maude code generation and verification has been integrated into Ptolemy II by Kyungmin 
Bae, so that a large subset of Ptolemy II DE models can be verified from within Ptolemy II. The paper H 
explains the Real-Time Maude semantics and formal analysis support for Ptolemy II DE models in detail. 

Figure [2] shows a hierarchical Ptolemy II model of a fault-tolerant traffic light system at a pedestrian 
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Figure 2: A hierarchical fault-tolerant traffic light system in Ptolemy II. 



crossing, consisting of one car light and one pedestrian light. Each light is represented by a set of set 
variable actors (Pred and Pgrn represent the pedestrian light, and Cred, Cyel and Cgrn represent 
the car light). A light is on iff the corresponding variable has the value 1. The state machine actor 
Decision "generates" failures and repairs by alternating between staying in location Normal for 15 
time units and staying in location Abnormal for 5 time units. Whenever the model operates in error 
mode, all lights are turned off, except for the yellow light of the car light, which is blinking. We refer 
to for a thorough explanation of the model. 

We have used Ptolemy IPs code generation infrastructure to integrate both the synthesis of a Real- 
Time Maude model from a Ptolemy II design model as well as Real-Time Maude model checking of 
the synthesized model into Ptolemy II itself. When the blue RTMaudeCodeGenerator button in a 
Ptolemy II DE model is double-clicked, Ptolemy II opens a dialog window (shown in Fig. [4]) which 
allows the user to start code generation and to give model checking commands to formally analyze the 
generated model. 

We have also predefined in our model checker useful atomic propositions similar to those in our 
AADL model checker. For example, the proposition 
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P. C. Olveczky 



guard: true 
output: Pred = 1 
Pgrn = 



Pstop 

Pgo 

Sec 




(Pred) 



^ (Pgreen) 



guard: Pgo_isPresent 
output: Pred=0; Pgrn : 

(a) Pedestrianlight 



guard: true 

output: Cred=l; Cyel=0; Cgrn=0 
set: count = 



guard: SecjsPresent 
output: Pgo=l; Cred=l 
Cyel=0; Cgrn=0 
set: count ■ /T^ -1 i 

Cyel 

guard: Sec_isPresent 
&& count= = l 

output: Cyel = l; Cgrn=0 



• count: 1 
Sec 




guard: SecjsPresent && count<l 
set: count = count +1 



guard: SecjsPresent && count < 2 
et: count = count + 1 
guard: SecjsPresent && count= = 2 
output: Cyel = l; Pstop=l PstOp 
set: count - ^^ 

Pgo 

H 

Cred 
Cgrn 
Cyel 



(Credyel J 



guard: Sec_isPresent 
output: Cred-0; Cyel-0; 

Cgrn=l 
set: count - 



(b) Carlight 



Figure 3: The state machine actors for pedestrian lights and car lights 

holds in a state if the value of the parameter var\ of the actor actorld equals value; for each 1 < i < n, 
where actorld is the global actor identifier of a given actor. Similarly, actorld | port p is value 
and actorld | port p is status hold if, respectively, the port p of actor actorld has the value value 
and status status. For state machine actors, the proposition actorld @ location is satisfied if and 
only if the actor actorld is in "local state" location. 

In the traffic light system, the following timed CTL property states that the car light will turn yellow, 
and only yellow, within 1 time unit of a failure: 

AG ( ( ' HierarchicalTraf f icLight . 'Decision | port 'Error is present) 

=> AF[<= 1] (' HierarchicalTrafficLight | 'Cyel=l, 'Cgrn=0, 'Cred=0)) 

Model checking this property revealed a previously unknown error: after a failure, the car light may 
show red or green in addition to blinking yellow. 



5 Timed Model Transformations in MOMENT2 

The MOMENT2 [6, 7] formal model transformation framework is based on a formalization of MOF 
meta-models in rewriting logic. The static semantics of a system is given as a class diagram (or meta- 
model) describing the set of valid system states (or models) that are represented as object diagrams, 
and the dynamics of a system is defined as an in-place model transformation. In MOMENT2, a model 
transformation is defined as a set of production rules. Each such rule 



rl / { nac dl nacl { NAC 

lhs { dl { L } } ; 



such that cond 
rhs { dl { R } 



when cond; 



} 



has a left-hand side L, a right-hand side R, a set of (possibly conditional) negative application conditions 
NAC, and a condition with the when clause. L, R, and NAC contain model patterns, where nodes are 
object patterns and unidirectional edges are references between objects. MOMENT2 provides a range of 
analysis methods in Maude, including a checking whether a model conforms to its meta-model as well 
as model checking of model transformations. 

In joint work with Artur Boronat, I have extended MOMENT2 to add timed behaviors to model 
transformations by providing a small and simple but useful set of built-in types for defining clocks, timers, 
and what we call timed values, which are clocks that increase with a given rate JSJ. As a consequence, 
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Figure 4: Dialog window for the hierarchical traffic light code generation. 

a software engineer can use MDA standards and Eclipse Modeling Framework (EMF) technology to 
formally analyze RTESs. 

This approach, where timed constructs have to be added to the original model to express timed be- 
haviors requires changing the structural design of the application. However, using MOMENT2's support 
for multi-model transformations, one can also define a timed system in a non-intrusive way, in which the 
user-defined meta-model of the system is not modified. See [ 8 ] for details. 

The Real-Time Maude semantics of timed model transformations is a fairly straight-forward ex- 
tension of the rewriting logic semantics of model transformations given in [5]. Although MOMENT2 
currently uses Maude as its execution engine, we can also easily perform Real-Time Maude inspired 
time-bounded analyses by just adding a single unconnected Timer — whose initial value is the time 
bound — to the initial state. When this timer expires, time will not advance further in the system, since no 
rule resets or turns off the timer. This ability to perform time-bounded analysis makes (time -bounded) 
LTL model checking analysis possible for systems with an infinite reachable state space, that can other- 
wise not be subjected to LTL model checking. 



6 Domain-Specific Visual Languages in e-Motions 

The e-Motions model transformation framework [26] for domain-specific visual languages is also based 
on EMF, with Ecore meta-models defining the abstract syntax of the language, and where the concrete 
syntax maps elements of the abstract syntax onto graphical objects. Although specification of system 
behaviors is based on in-place model transformations, the approach to timed behaviors is different from 
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the one taken in MOMENT2. Instead of adding external "timed constructs," e-Motions tries to make the 
definition of timed model transformations as intuitive and high-level as possible by providing different 
kinds of timed model transformation rules. 

A model transformation rule is equipped with a time interval that defines the range of the possible 
durations of the rule, which is applied eagerly. A rule can, however, be declared to be soft, which 
means that it is not triggered eagerly, and/or may be declared to be periodic, in which case it is triggered 
periodically as long it is enabled. In addition to atomic rules, there are also ongoing rules that model 
continuous actions. These are powerful high-level constructs that typically imply that many different 
timed rules are being applied simultaneously to an object. 

e-Motions has a Real-Time Maude semantics. e-Motions models can be simulated visually in the 
e-Motions tool, which is available as an Eclipse plug-in. For reachability and LTL model checking 
analyses, however, the tool generates the corresponding Maude model, and the analysis has to be done at 
the Maude level. However, the operator <<_;_>> is useful to define analysis commands without having 
to know the Maude representation of an e-Motions model. The term << ocl-expr ; model » evaluates 
the OCL expression ocl-expr in the model model. Therefore, to search for a model reachable from an 
initial model myModel that satisfies the OCL expression ocl-expr, we use the Maude command 

search [1] init (myModel) =>* {MODEL : @Model } in time T:Time 
such that << ocl-expr ; MODEL: @Model >> . 

7 A Modeling Language for Handset Software 

In HI , Musab AlTurki and researchers at DOCOMO USA Labs describe a simple but powerful spec- 
ification language, called Jz? , that is claimed to be well suited for describing a spectrum of behaviors 
of various software systems. The language provides flexible SDL-inspired timing constructs that yield 
a more expressive language for timed behaviors than Erlang [12], since some nested timing patterns, 
which can be expressed in Jz? , are not expressible in Erlang HI. 

The language has an expression language, imperative features for describing sequential computa- 
tions, and asynchronously communicating processes that can be dynamically created or destroyed. It is 
worth remarking that just the dynamic process creation places J2? outside the class of systems that can 
be represented as timed automata; so does its expression language and imperative features which make 
J2? Turing-complete. 

The semantics of of Jzf is defined in Real-Time Maude, and Real-Time Maude therefore also provides 
a prototype analysis tool for ££ . However, there does not seem to be any support for automatically 
translating Jf specifications into Real-Time Maude models. 

8 Concluding Remarks 

This paper has motivated the use of Real-Time Maude as a target formalism and tool that should be well 
suited to support the formal model engineering of real-time embedded systems, and has given a brief 
overview of the use of Real-Time Maude for such purposes. 

Much work remains as always, including covering other languages and larger subsets of the lan- 
guages mentioned in the paper. Furthermore, although we can predefine useful propositions so that the 
user can easily define his/her own queries, and although there is a one-to-one correspondance between 
the informal and the formal model, results from the formal analyses should still be mapped back into the 
original formalism. 
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